问题描述：

继上次写博客记录的el-table+el-dialog的bug之后--

elementui el-table中每行嵌套的el-dialog的scope取值bug_el-table 行嵌套_FC_oder的博客-CSDN博客s

今天又遇到了类似的问题：在el-table-column中嵌套使用el-dialog时，出现了dialog内容加载卡顿的问题

问题代码：（偷懒直接贴了上篇博客的）

问题分析：

项目中dialog需要渲染的是每种原油的70多种属性的数据，el-table负责对多种原油的属性数据进行渲染，在点击详情后弹出dialog展示对应油种的属性数据。

项目一开始的方案是在页面mounted钩子中直接向后端请求页面中所有的数据。然后在测试详情按钮的时候发现了本篇文章所描述的问题。

一开始认为问题出在el-table中所需渲染的列表（从后端请求得到的）数据过大导致的问题，这边让后端做了数据分页后，发现问题没有得到明显改善。

因此这边想到的第二个方法是在点击详情后，给dialog中加个elementui的加载样式，等到dialog中的元素渲染完毕后再关闭加载样式。这边采用了动态增加加载样式的方式，获取到classname为el-scrollbar__wrap的元素列表。

然而在测试时发现并没有出现期望的加载样式，并且打印出来的elem足足25个之多。

这边终于才恍然大悟，原来dialog重复渲染了多次，在点击某个详情按钮时，增加的加载样式并不一定是显示在最顶层的dialog上。也正因为重复渲染，在dialog中节点数量较多的时候，会造成明显的卡顿。

而一开始未能及时排查出重复渲染问题的原因是，虽然重复渲染了多次dialog，但每个dialog所绑定的开启事件和关闭事件是完全相同的，打开和关闭dialog过程中除了加载略卡，其他并无异样。

因此，最终的解决方案也很简单，将dialog提出到el-table之外即可。

随后，这里我也是抱着一定的好奇心稍微研究了一下el-table的源码。 其中，el-table-column的核心代码可以参考这篇博客：

element-ui的el-table源码分析 - 掘金

可以看到，el-table底层的逻辑是将待渲染的列表遍历一遍，同时column内的template中所有的元素会被遍历渲染。也验证了我的猜想。

总结：

目前认为最优的解决方案是将写在column内的dialog抽出在外层div写。因为el-table底层的逻辑是将待渲染的列表遍历一遍，同时column内的template中所有的元素会被遍历渲染。如果dialog写在column内除了会发生上一篇文章提到的问题之外，还会因为渲染过多重复节点出现性能问题。

欸，感觉这个问题还挺基础的。第一次发文章碰到这个问题的时候急着赶项目进度，没有仔细分析问题背后的原因。今天再次碰到类似的问题了，才静下心来的进行分析。希望自己在学习的过程中能多多积累类似的追根溯源的经验与能力。